微博衡量服务器抗压能力的新单位——“星轨”(明星的星，出轨的轨)
前段时间，二胖在网上看到一个词儿——“星轨”，说是新浪微博衡量服务器抗压能力的新单位，当时我就觉得既形象又有趣，还有些搞笑。
先给大家解释一下什么是星轨。
一星轨表示一个一线明星出轨所带来的流量，据说微博的服务器现在能同时扛8星轨。
也就是说：8个一线明星同一时间爆出出轨的新闻，微博都能扛得住！
当然哈，这只是一句调侃的话，用于证明微博服务器的抗压能力已经很强了。
其实，微博的程序员小哥们可真不容易，因为微博的流量波动是很难预测的，指不定什么时候出来一个热点话题，微博的流量就会垂直上升。
这也是微博和其他网站最大的区别。
淘宝、地图、京东这些应用平时的流量是很稳定的，不会出现短时间的暴增也不会出现断崖式的下跌。
在一些特殊时点，比如双十一，淘宝的工程师们会提前增加N倍的线上服务器，而京东的工程师们早就做好了迎接618的准备，地图的同学们也早在节假日之前就扩充了服务器。
也就是说，上述应用都能准确知道自己的流量高峰会在什么时候出现，所以可以在流量高峰到来以前扩充服务器资源，保证自己的应用能够正常运行。
可能有同学会疑问，为什么平时不多部署一些机器呢？这样服务就不怕流量暴增了哇。
道理是这么个道理，可是事儿不是这么个事儿。服务器资源是比较昂贵的，平时部署太多的机器会徒增很多额外的开销，所以大部分企业平时都只会部署能承受正常流量3~4倍流量的机器。
它们采取的方式都是在流量高峰到来之前扩充更多的服务器（不少企业都是租用亚马逊、阿里云等云服务提供商的服务器），用完之后就释放，这样能节约不少成本。
而微博就很无奈了，因为它无法预测流量高峰，谁也不知道明星们啥时候就搞个出轨或是其他新闻出来，流量短时间暴增，微博的服务器就扛不住了。
下图是邓超2015年12月20日刷屏的微博，那一天他的刷屏就把微博服务器给搞挂了不少。
我们可以看到，上图中，邓超发布的微博评论量都是10万以下，加起来也不过几十万，这并不是一个很大的数字，至少和明星出轨、偷税漏税这种新闻比起来，流量算小的。不过即使是这样，也都把微博服务器搞挂了，那明星出轨能带来多大流量呢？
下图是2014年文章爆出出轨新闻后马伊琍的回应微博截图，评论过百万，转发46万。
2015年陈赫出轨后认错的微博评论更是高达299万。
所以，微博的程序员们最怕什么？
不是怕代码出bug。
怕的是明星出轨。
而和明星出轨比起来，程序员们更怕的是明星出轨的新闻被晚上爆出来。
一个明星的出轨可能会导致几十个、上百个人半夜爬起来加班。
所以，各位大佬，请别出轨了，就算要出轨，请一定要在工作日的正常工作时间被曝出轨，程序员很辛苦的。
好不容易要下班了，WTF？？？
下面这一条微博带来的流量起码等于三个一线明星同时出轨带来的流量。
程序员内心OS：
加班！加班！加班！
在无休止的加班中，程序员小哥哥们终于忍不住了，想着要改变这个现象！！！
所以，程序员们日夜不休地优化代码，终于！微博的抗压能力上去了！
现在能扛8星轨，8个明星同时出轨也不虚了。
最近没有听说明星出轨的新闻把微博服务器搞挂的消息了吧。
好啦，段子讲完了，下面来点干货，今天给大家聊一聊“消息队列”，以及如何用“消息队列”来应对大流量高并发下用户提交内容的入库问题。
在讲消息队列之前，先给大家介绍一个互联网术语——UGC。
下面对UGC的解释来自百度百科：
“互联网术语，全称为User Generated Content，也就是用户生成内容的意思。UGC的概念最早起源于互联网领域，即用户将自己原创的内容通过互联网平台进行展示或者提供给其他用户。UGC是伴随着以提倡个性化为主要特点的Web2.0概念兴起的。”
在本文中，大家可以认为UGC指的是用户的评论内容。
下图是互联网企业在线服务常见的部署方式：
当用户发送请求之后（评论操作或者消息请求操作），中转设备就把流量分摊到集群中的各个物理节点上，比如使用Nginx做代理以及负载均衡。
当流量短时间暴增的时候，假设正常情况下一台服务器的qps（每秒的请求量）是300，突然某个明星出轨的事情上热搜了，qps暴增到3000，导致其中某些稍微脆弱的服务器先跪了，那么剩下的服务器就要承担更多的流量（跪了的服务器的流量被分到了其他剩下的服务器上），服务器承受的压力越来越大，然后就一台一台地跪了。
相信大家都知道，对于存储系统而言（比如MySQL，MongoDB等），正常情况下的写入压力、更新压力是大于查询压力的，而恰好，微博的评论短时间轰炸，后端集群只要有一个环节扛不住就很容易瘫痪了，这时候用户看到的结果就是——操作无响应。
那么问题来了，我们该怎么去应对这种情况呢？
给在线服务加一个消息中间件是个不错的选择。
什么是消息中间件？
百度百科对消息队列的解释是“在消息的传输过程中保存消息的容器”。
我相信很多朋友看了这个解释也还没有明白什么是"消息队列"，所以我们还是以微博为例来看一个具体的场景。
这里我们做一个抽象，把产生消息的用户比喻成生产者，把服务器集群比喻成消费者（生产者消费者是不是很熟啊，哈哈，学过操作系统的同学肯定很熟）。
我们在生产者和消费者之间加了一个中间件——消息队列，用它可以来干嘛呢？
它是来做消息转发的，当请求过来之后，不是直接发给服务器，而是发给消息队列，然后消息队列把消息中转一下再发给服务器。
很多同学可能会想，这不是多此一举吗？
其实不然。
消息队列可以把消息分类，分别下发，比如点赞、评论和转发，各自走各自的通道。
消息队列可以暂存消息。当用户的请求到达消息队列以后，消息队列就给用户发出响应，显示评论成功，即使这时候该评论还没写入数据库，可是用户是不感知的。当流量暴增的时候，生产者生成的消息大于消费者的处理能力，消息就会先被暂存在消息队列里，然后消费者全力去处理，这样就避免了服务器压力过大。消息队列并不是全部存储在内存中，也是可以写入硬盘的，所以能存储很大量的消息。
这里二胖只是给大家介绍了消息队列相关知识的冰山一角，更多的知识，大家可以下来自己去了解。
两个常见的消息队列，Redis、KafKa。
近期热文
给你小鱼干!